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1. INTRODUCTION 


The False Event Elimination project applied Expert System techniques to improve discrimination 
between true and false detections made by a mission data processor. The goal was to build a prototype 
system that demonstrated good discrimination performance against recorded mission data, and provided 
clear specification of the factors considered in each decision. 

Two computer programs were developed in the project. A demonstration decision-making system was 
built consisting of an expert system coupled to pattern recognition and correlation programs. A mission 
display program was also created in order that the expert system developers could see the data normally 
available to the human operators. This report describes the expert system that was implemented in the 
demonstration. 

Section 2 describes the overall expert system approach, why it was chosen, and an evaluation of the 
system as it currently operates. Section 3 describes the rule-based knowledge in the system, which is 
our functional model of the operator's decision process. This section includes the input features provided 
to the expert system and the logic involved in making a decision about the event. Finally, Section 4 
explains many of the details of the implementation of the expert system program. 

It is recognized that the rule base presented here has flaws, however the intent was to model a 
reasonable amount of the knowledge to provide a baseline system for demonstration of feasibility and 
capability. It will be a test of the expert system approach to have other experts improve upon what we 
have done. 
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2. DESCRIPTION OF THE DEMONSTRATION 
SYSTEM 

2.1. OVERVIEW 

In this project we are developing an “intelligent" algorithm to analyze remotely sensed data collected by 
satellite. It is an example of adding an expert system to an existing signal processing program. 

At present, a signal processing computer analyzes time-varying patterns in the collected data in order 
to infer that actual changes or "events" have occurred in the real world. In addition, the computer displays 
a filtered version of the data superimposed upon a map. When the computer finds a specified pattern, it 
notifies the display operator that a potential event has been found. The operator judges whether the 
event is true or false, i.e. whether or not the pattern corresponds to an actual event, by examining both 
the pattern and its context within the display. In almost every case the operator correctly identifies true 
events and eliminates false events that were not rejected by the computer. 

The goal of the project is to reduce the number of false events reported and ultimately to create an 
autonomous system. The first stage is to provide an "intelligent assistant" to unseasoned display 
operators by providing expertise usually only available from systems engineers and analysts. 

This report will describe an expert system which is being built to discriminate selected patterns, "true 
events", from many other signals, such as noise and other unwanted sources. The system must handle 
information about sensors, such as their operation and failure modes, about natural phenomena, such as 
reflections off ice-capped mountains, and about the particular pattern which must be distinguished from 
noise and other signal sources. 

Figure 1 depicts the organization of the expert system. The system begins with initialization, the data 
case is selected, and the tables are read. The bold arrows in the diagram show the main course through 
the system. The elements composing each of the blocks will be explained in the following sections. 

2.2. KNOWLEDGE BASE 

An expert system was chosen over a standard programming approach for a few reasons: the ease in 
adding knowledge and in modifying existing knowledge without major reprogramming, the interactive 
capabilities for explanation, verification, and debugging, and the independence of the knowledge base 
from the inference system (changing or replacing either will not affect the other). 






























The knowledge base is an independent table of production rules that encapsulate the relevant 
knowledge of satellite systems engineers and data processing analysts as to the causes of false events 
and the patterns of "good" events. One of the authors, Paul Mazaika, was able to be both knowledge 
engineer and domain expert, which greatly facilitated knowledge acquisition. He interacted with other 
experts to develop rules which cover the hardware, software, and phenomenology aspects of making a 
decision regarding a possible event. 

The scope of the knowledge base includes the functioning of the hardware, both in known correct 
states and in possibly erroneous states, the current configuration of the adaptive software, and the 
possibility of phenomenological sources causing spurious noise and clutter. This knowledge is "static" in 
the sense that the rules do not change during the analysis done by the expert system of a given case. 
The order and selection of rules may vary, but the set of rules in the knowledge base are constant. 
However, as the knowledge base is first being written and as it goes through an evolution until it reaches 
a mature form, the set of rules will be created and modified. The knowledge base may be developing 
even when the expert system is in full operation as additional information is found to be relevent or 
present information is reevaluated. 

The rules in the knowledge base are structured as if-then-else clauses, 

i. e. if condition(s) 

then consequence 
else consequence 

There may be numerous conditions leading to a single consequence. The conditions may be 
combined by using "and", "or", or "not". If the conditions evaluate to true the "then" consequence is 
asserted; if they are false the "else" consequence will be asserted. For example: 

If the event is in a mountainous area and 
the event is in local daylight 
Then a known phenomenology source is near the event 
Else reflections from the mountains are not the cause. 


If the two conditions are true, the fact that a phenomenology source is nearby will be asserted and 
made available for use as a condition in other rules. Similarly, if the conditions evaluate to false, which will 
happen if either one or both of the condition clauses are false, then the 'else" clause that the event is not 
caused by reflections from the mountains will be asserted. 

Since information about the satellite sensors, the phenomenology, and the event is rarely known with 
100% certainty, each assertion is weighted by a confidence level. 

likelihood internal truth-confidence 


very likely 
somewhat likely 
very unlikely 


true with high confidence 
true with medium confidence 
false with high confidence 













The expert system was originally set up to handle an expanded set of likelihoods which includes the 
following. 

likelihood internal truth-confidence 

unlikely true with low confidence 

somewhat unlikely false with medium confidence 

possibly unlikely false with low confidence 

These last few are not being used because of the significantly greater number of rules needed to 
handle this many possibilities, as well as the fact that the operator who uses the system interactively 
wouid have a harder time choosing from 6 possible likelihood states than from 3. Thus, we now have a 
3-tiered logic. 

The dynamic system knowledge is stored in an assertion table which is separate from the static 
knowledge base. It stores the current state of what is known by the expert system and has all the 
assertions about the satellite system and the results of the "implicit" calculations. The inference engine 
determines the state of knowledge by executing the rules in the knowledge base and then updating this 
table as new assertions are made. 

2.3. INFERENCE ENGINE 

The expert system is data driven. The rules are organized into a hierarchy of several levels. Each 
level contains rules whose conditions are the consequences of rules on a lower level. At this stage of 
development, the ordering of levels was done manually, covering 11 levels at present. However, in the 
future we will have the precedence determined automatically. 

The lowest level is called "implicit", containing the data reduction routines which are automatically 
initiated once the satellite data tape is selected. These routines do pattern recognition tasks and analysis 
of the events and the other returns in their proximity. The results are returned to the main system and are 
stored in the assertion table. Representative calculations are: 

1. solar geometry angles as a function of time 

2. nearby noise sources 

3. data clustering 

4. distances to selected features of the terrain 

5. satellite sensor problems such as strobe and ringer noise. 

After the implicit level has been executed, subsequent levels apply the rules in the knowledge base to 
what is then known about the event, the satellite, and the event's environment, as recorded in the 
assertion table. This is done by the inference engine which drives the expert system, executing rules at 
each level. On the top level a decision on the validity of the event is made For each level the inference 
engine goes through the following stages 
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1. Select the next rule, sequentially going down the list of rules for the level being considered. 

2. Determine if the rule has previously been evaluated. If it has, go to the first step and select 
another rule. 

3. Decide whether there is enough information available to evaluate the rule. This is done in 
two passes through the rules on each level. The conditions of the rules are compared to 
assertions in the knowledge base to determine what the current state of knowledge is. On 
the first cycle through, if there is missing information we skip the rule and go on to the next. 
However, on the second cycle, missing information puts us into "interactive mode" where 
the expert system asks us about the assertion. 

4. The next step is to evaluate the truth of the antecedent condition(s), setting the "then" 
conclusion to true if they evaluate to true and, K there is an "else" conclusion, setting that to 
true if the conditions evaluated to false. 

5. The concluding assertion is stored in the assertion table, and all rules which reach this 
same conclusion are flagged so that they are not evaluated again. 

6. Then the process starts again, selecting the next rule until all the rules on the level have 
been attempted; this is cycle 1. The second cycle through the rules captures those with 
missing information. After the second cycle, the next level is entered, until the highest level 
is reached. 


2.4. INTERACTIVE MODE 

As mentioned above, during the second cycle through the rules, when the expert system is ready to 
evaluate a rule for which the truth of the conditions is not known, interactive mode is entered. The 
following example is a question which must still be answered by the user as to the health of the satellite 
system and sensors. 

»> Is the satellite system functioning properly? 
truth value(true/false/unknown): t 
confidence level(high/ m ed ium /low/unknown): m 


At present, the expert system must rely on experts to decide whether something has gone wrong. In 
the future, the expert system will have enough knowledge to answer most, if not all, of the questions. It is 
worth noting that it may be a valuable feature of the computer system to continue to ask the human 
expert to make certain evaluations which are beyond its scope and capabilities. 

2.5. QUERY MODE 

Besides interactive questioning of the user, this prototype has an explanation feature that allows a user 
to interrogate the system about the current state and about the logic flow (i.e., the rules used). This 
explanation feature is extremely useful in debugging the rule base, and in substantiating the credibility of 
the inference engine. 

The query mode is able to trace the system operation in a step by step fashion in such a style that the 
logic flow of the system can be understood by a non-programmer. The program is able to inform the user 
in easily understood terms what it did and why it did it, thereby instilling confidence in its operation. This 










also makes it easier for the user to see what enhancements are necessary to the rule-base. 


When the truth of a condition is unknown the system will request information from the operator. At this 
time interactive mode is entered. To gain additional information about why the computer asked the user a 
question, or to find what capabilities for explanation the system has, the user may enter query mode by 
typing *?". The system then gives a menu of the options. 

truth Values Confidence Levels General 


true 

false 

unknown 


high 

medium 

low 

unknown 


? for help 
+ for explain 
rule 

search tables 


A response of “+" to a system query will cause the system to give further explanations about what 
information is needed. A reason why it is relevant may be included. Typing "r" or "rule" will give the 
specific rule which the system was trying to evaluate when the system found it did not know the truth of a 
condition, thus necessitating the questioning of the user. The last option is to search the tables: the rule 
base, the value/assertion table, and the limit/threshold table. Typing an "s" or "search" gives this menu: 

Nould you like to see any of the following? 

1) rules s) by rule# 

b) by phrase 

c) explanation of rule# n 

d) by level 

2) values/assertions a) by name/phrase 

b) explanation of value# n 

3) limits a) by name 

Please enter selection or 0 to end: 


While this is presently mer.u driven, we hope to convert this to a more natural interaction, i.e., closer to 
English, with the user typing "search" and the computer prompting the user for which table and what kind 
of information is desired. We have left the interactive capability limited, spending the major part of our 
effort on the technical and systems aspects of the "intelligent assistant". 

Running concurrently with the expert system is a display screen which enables system users to visually 
monitor the data. The user is able to examine the patterns in the data in the context of the display, which 
has the data superimposed upon a map. This facilitates the detection of flaws or inadequacies in the logic 
of the computer system as well as those in the data or the sensors which measured the data. This display 
is also a convenient debugging aid for testing rules in the prototyping effort, and as a double check of 
relevant calculations. 












2.6. STATUS 


To write the expert system, we have used C on both a VAX 11/780 and an Apollo workstation. This 
decision makes interfacing to procedures which do intensive numeric calculations straightforward. C is 
presently fairly easy to port to other computers, especially micros and small computers, making the idea 
of a stand alone "intelligent assistant" more likely. That C is much faster than the typical Artificial 
Intelligence languages is a crucial factor in this time-critical application. With quick execution, debugging 
of the rule base and the software takes less time and is more comprehensive, since a fairly large number 
of cases may be run in a reasonable amount of time. 

The rule base contains about 200 rules at present. This rule set covers most of the "typical" causes of 
false event reporting. We are currently adding rules to handle the infrequent and poorly understood 
cases. It is anticipated that the final rule base will contain 300-500 rules. 

There are only two or three assertions, depending on which rules need to execute for a given set of 
data, which cause the system to enter "interactive mode", to query the user. The test cases which we 
have run yield a correct evaluation in 23 out of 27 cases, which is about an 85% accuracy. The 
knowledge base was built independent of these data sets, so this is a fair estimate of the performance of 
the system. 

The speed with which the system ran is close to real time. Although the system has not been optimized 
to run quickly, the cpu time for a run for over 80% of the cases was under a minute, and all of them ran 
with a cpu time under 1.5 minutes. 

2.7. CONCLUSIONS FOR THE PROTOTYPE SYSTEM 

In conclusion, we find the expert system to be a viable approach to event discrimination. Despite the 
wide variety of data and the numerous ways in which that data must be manipulated, the expert system 
initiates the data reduction procedures, feeds the results into the assertion table, and does analysis of 
them in the inference engine via the knowledge base. The structure of an expert system, which has the 
knowledge base independent of the inference mechanism, greatly facilitates maintainability and growth. 
New knowledge may be added to the system without having to do any reprogramming. Additional numeric 
routines may be added simply by updating a table of procedure names. The knowledge base may also be 
modified or enlarged by making entries into the table containing the rules. 

The final decision which the system reaches for a number of test cases is encouraging. The expert 
system determines the validity of events correctly with a success rate an order of magnitude better than 
the current signal processing software. And we are still in the feasibility stage with an immature 
knowledge base. 

Since the knowledge base and expert system software are still growing, we expect to further improve 
the performance. We plan to run the system in the field as an "intelligent assistant" to evaluate the 











3. A MODEL OF THE OPERATOR’S KNOWLEDGE 


3.1. LOGIC FLOW 

The expert system is data driven, meaning that it is the data which drives the flow through the rule 
base. The overall logic flow is shown in Figure 2, leading from input features on the bottom to the 
true/false decision at the top. Local clutter is estimated by known phenomenology sources, observed 
data on the mission display, and inferred data from the proximity of blanks. 

These factors and the knowledge gained by viewing the event on a mission display give an 
understanding of the local background. Combining this with an evaluation of the reliability of the individual 
returns comprising the collected event and the noise level in the vicinity give a technical evaluation' of the 
event. 

This evaluation, combined with the user’s expectation of seeing a true event and knowledge about the 
health of the sensors, the satellite, and the on-board processing leads to the final decision. 

In the diagram, some of the implicit features, i.e., parameters resulting from the implicit level 
calculations, are listed beneath the boxes which contain the assertion for which they are inputs. 
Following the diagram are listings of the implicit features and the rules in the knowledge base. The 
implicit level is considered to be level 1, so the expert system rules start with level 2. There are about 40 
implicit features and 200 rules in all. 
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Figure 2. Basic Rule - Logic Flow 

























3.2. IMPLICIT LEVEL DATA REDUCTION 





The first level of the expert system does data reduction. This is accomplished via a set of "implicit” 
routines, so designated because the calculations provide basic information about the state of the system 
without being explicitly developed by rules in the knowledge base. Only the numeric results of the 
calculations are available to the inference engine or the user in Query Mode. 

The following is a list of the implicit knowledge being calculated: 

1. distance to the horizon 

2. distance to the coast 

3. probability that the event is caused by noise 

4. a flag whether the event is over land or sea 

5. the maximum event intensity 

6. a flag whether the intensity pattern is "reasonable" 

7. distance to the terminator 

8. distance to the terminator in 20 minutes 

9. a flag whether the event is in a mountainous region 

10. angular distance to the sun 

11. the scattering angle 

12. the specular point 

13. local number of events 

14. number of points passing stationary source test 

15. number of points passing transient noise test 

16. number of non-overshoot points 

17. number of non-persisting returns 

18. number of non-over-the-horizon points 

19. number of non-event points in proximity 

20. distance to the solar blank 

21. distance to the lunar blank 

22. distance to the closest high threshold adaptive area 

23. distance to next closest high threshold adaptive area 

24. a flag whether the solar blank is stationary 

25. a flag whether the closest adaptive area blank is stationary 

26. a flag whether the next closest adaptive area blank is stationary 

27. a flag whether the lunar blank is stationary 

28. the number of points revealed by a moving solar blank 

29. the number of points revealed by a moving lunar blank 
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30. the number of points revealed by a changing closest adaptive area 

31. the number ot points revealed by a changing next closest adaptive area 

32. a flag whether the event is in an Arctic ice region 

33. a flag whether the event is in a region which has a history of background sources 

34. the number of points in the collected event 

The following is a list of the features that are not automatically calculated in the present version, rather 
they may be entered by the user. Usually only two inputs (expectation and functioning properly) are 
required from the user. 

1. non-natural background 

2. the expectation of an event 

3. the system is functioning properly 

4. attitude is the only error 

5 ’he event is caused by a star (or celestial body) 












3.3. KNOWLEDGE BASE 


! level 2 

rule 104 

If distance to horizon >■ horizon threshold 
Then the event is not close to the horizon [high conf] 

This rule is used to separate out possible background sources. 

\ rule 101 

If probability that the event is caused by noise > max noise confidence threshold 
Then the event is due to noise [high conf] 

s The noise thresholds are set so that 4 raw returns in the event imply 

' the event is not noise, 3 raw returns imply the event might be noise, and 2 

or fewer imply the event is noise. Adjacencies count as 2 raw returns. It 
would be better to take intensities into account, but this is not done. 

1 rule 102 

j If probability that the event is caused by noise < min noise confidence threshold 

] Then the event is not due to noise [high conf] 

1 The noise thresholds are set so that 4 raw returns in the event imply 

the event is not noise. 3 raw returns imply the event might be noise, and 2 
or fewer imply the event is noise. Adjacencies count as 2 raw returns. It 
■ would be better to take intensities into account, but this is not done. 

I rule 103 

| If probability that the event is caused by noise >«= min noise confidence threshold AND 

probability that the event is caused by noise <= max noise confidence threshold 
Then the event is due to noise [medium conf] 

i The noise thresholds are set so that 4 raw returns in the event imply 

* the event is not noise, 3 raw returns imply the event might be noise, and 2 

< or fewer imply the event is noise. Adjacencies count as 2 raw returns. It 

! would be better to take intensities into account, but this is not done. 

; rule 105 

! If the origin of the event - land 

| Then the event is over the land [high conf] 

! Else the event is over the sea [high conf] 


If the event is close to a coastline, the land/sea decision could be 
in error. 

rule 112 

If the origin of the event - land 

Then the event is over the land [high conf] 

Else the event is not over the land [high conf] 


If the event is close to a coastline, the land/sea decision could be 
in error. 


8 










rule 106 

If the intensity pattern > profile fit threshold 
Then the intensity profile is reasonable [high conf] 

Allowable profiles either have a single hump, or the last intensity is 
the highest. Logic is for three point events only. 

rule 107 

If the intensity pattern < profile fit threshold 

Then the intensity profile is not reasonable [high conf] 

Allowable profiles either have a single hump, or the last intensity is 
the highest. Logic is for three point events only. 

rule 109 

If the event intensity < intensity threshold 
Then the event intensity is less than 200 [high conf] 

Else the event intensity is not less than 200 [high conf] 

The event’s intensity will rule out certain background sources. 

rule 113 

If the region is mountainous = mountainous region 
Then the event is in a mountainous area [high conf] 

Else the event is not in a mountainous area [high conf] 

The mountainous regions are roughly defined by a 100 point world-wide 
data base. 

rule 114 

If distance to terminator < near terminator max AND 
distance to terminator > near terminator min 
Then the event is near the terminator [high conf] 

Distance to terminator is used to estimate how ctose an event is to 
being sunlit. 

rule 115 

If distance to terminator > near terminator max AND 
distance to terminator < far terminator max 
Then the event is near the terminator [medium conf] 

Distance to terminator is used to estimate how close an event is to 
being sunlit. 

rule 116 

If distance to terminator > far terminator max 
Then the event is not near the terminator [high conf] 

Distance to terminator is used to estimate how close an event is to 
being sunlit. 

rule 117 

If distance to terminator < far terminator min 
Then the event is not near the terminator [high conf] 


Distance to terminator is used to estimate how close an event is to 






being sunlit. 
rule 118 

If distance to terminator < near terminator min AND 
distance to terminator > far terminator min 
Then the event is near the terminator [medium conf] 

Distance to terminator is used to estimate how close an event is to 
being sunlit. 

rule 119 

If angular distance to sun < telescope angular width 
Then the sun is in the telescope’s field-of-view [high conf] 

The sun diameter is 1/2 degree, the telescope diameter is taken as 9 
degrees. If the sun center is within approximately 5 degrees of the 
telescope axis, then is directly in the telescope field-of-view. 

rule 120 

If angular distance to sun > optical off-axis max angle 
Then the sun is not in the telescope’s field-of-view [high conf] 

The sun should not be a problem unless there is an anomaly in the 
telescope. 

rule 121 

If angular distance to sun >= telescope angular width AND 
angular distance to sun <« optical off-axis max angle 
Then the sun is in the telescope’s field-of-view [medium conf] 

When the sun is close to the field-of-view, diffraction and internal 
scattering can cause spurious data. The limits of 5 degrees to 10 degrees 
are a guess for the bounds of the optical off-axis rejection function. 

rule 122 

If scattering angle <= min scattering angle 
Then the scattering angle is unfavorable [high conf] 

Values from S.J. Young report. SAMSO TR-78-178. 

rule 123 

H scattering angle > min scattering angle AND 
scattering angle < max scattering angle 
Then the scattering angle is unfavorable [medium conf] 

Values from S.J. Young report. SAMSO TR-78-178. 

rule 124 

If scattering angle >» max scattering angle 

Then the scattering angle is not unfavorable [high conf] 

Values from S.J. Young report. SAMSO TR-78-178. 

rule 125 

If specular point < min specular refl angle 

Then the reflection geometry is unfavorable [high conf] 
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The BiReflectional Distribution Function tells the distribution of 
energy reflected in the specular direction. The estimate used here us 
that most energy is within 5 degrees and some energy is within 20 degrees. 

rule 126 

If specular point >- min specular refl angle AND 
specular point <- max specular refl angle 
Then the reflection geometry is unfavorable [medium conf] 

The BiReflecttonal Distribution Function tells the distribution of 

energy reflected in the specular direction. The estimate used here us 

that most energy is within 5 degrees and some energy is within 20 degrees. 

rule 127 

If specular point > max specular refl angle 

Then the reflection geometry is not unfavorable [high conf] 

The BiReflectional Distribution Function tells the distribution of 
energy reflected in the specular direction. The estimate used here us 
that most energy is within 5 degrees and some energy is within 20 degrees. 

rule 128 

If number of points passing stationary source test <= low stationary source threshold 
Then event is not free of stationary sources [high conf] 

rule 129 

If number of points passing stationary source test >= high stationary source threshold 
Then event is free of stationary sources [high conf] 

rule 130 

If number of points passing stationary source test > low stationary source threshold AND 
number of points passing stationary source test < high stationary source threshold 
Then event is free of stationary sources [medium conf] 

rule 131 

If number of points passing transient noise test <= low transient noise threshold 
Then event is not free of transient noise bursts [high conf] 

rule 132 

If number of points passing transient noise test >= high transient noise threshold 
Then event is free of transient noise bursts [high conf] 

rule 133 

If number of points passing transient noise test > low transient noise threshold AND 
number of points passing transient noise test < high transient noise threshold 
Then event is free of transient noise bursts [medium conf] 

rule 134 

If number of non-overshoot points >■ three 
Then the event is not overshoot data [high conf] 

rule 135 

K number of non-overshoot points = two 
Then the event is overshoot data [medium conf] 

rule 136 

If number of non-overshoot points < two 
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Then the event is overshoot data [high conf] 
rule 137 

If number of non-persisting returns >= three 
Then the data is not due to persistence [high conf] 

rule 138 

If number of non-persisting returns - two 
Then the data is due to persistence [medium conf] 

rule 139 

H number of non-persisting returns < two 
Then the data is due to persistence [high conf] 

rule 140 

If stationary solar blank «= zero 

Then the solar blank is not stationary for the event duration [high conf] 

Else the solar blank is stationary for the event duration [high conf] 

rule 141 

If stationary lunar blank - zero 

Then the lunar blank is not stationary for the event duration [high conf] 

Else the lunar blank is stationary for the event duration [high conf] 

rule 159 

If stationary closest adaptive area blank - zero 

Then the closest high threshold adaptive area is not stationary [high conf] 

Else the closest high threshold adaptive area is stationary [high conf] 

rule 160 

If stationary next closest adaptive area blank - zero 

Then the next closest high threshold adaptive area is not stationary [high conf] 
Else the next closest high threshold adaptive area is stationary [high conf) 

rule 142 

If the number of points in the collected event >- five AND 
number of non-event points in proximity >- thirty-five 
Then there is significant random clutter [high conf] 

rule 143 

If the number of points in the collected event >- five AND 
number of non-event points in proximity >- ten 
Then there is not significant random clutter [high conf] 

rule 144 

If the number of points in the collected event >- five AND 
number of non-event points in proximity < thirty-five AND 
number of non-event points in proximity > ten 
Then there is significant random clutter [high conf] 

rule 145 

If the number of points in the collected event < five AND 
number of non-event points in proximity > twenty 
Then there is significant random clutter [high conf] 

rule 146 

If the number of points in the collected event < five AND 
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number of non-event points in proximity < six 
Then there is not significant random clutter [high conf] 

rule 147 

If the number of points in the collected event < five AND 
number of non-event points in proximity > six AND 
number of non-event points in proximity <= twenty 
Then there is significant random clutter [medium conf] 

rule 148 

If the event is in a historical background region > zero 
Then some IR background is normally in this area [high conf] 

Else some IR background is not normally in this area [high conf] 

rule 152 

If the region is Arctic ice > zero 

Then the event is near Arctic ice [high conf] 

Else the event is not near Arctic ice [high conf] 

rule 157 

If stationary closest adaptive area blank > zero 

Then the closest high threshold adaptive area is stationary [high conf] 

Else the closest high threshold adaptive area is not stationary [high conf] 

rule 158 

If stationary next closest adaptive area blank > zero 

Then the next closest high threshold adaptive area is stationary [high conf] 

Else the next closest high threshold adaptive area is not stationary [high conf] 

rule 173 

If points revealed by moving solar blank > one OR 
points revealed by moving lunar blank > one OR 
points revealed by changing closest adaptive area > one OR 
points revealed by changing next closest adaptive area > one 
Then suspected points are partially hidden by a blank [high conf] 

rule 174 

If points revealed by moving solar blank = zero AND 
points revealed by moving lunar blank = zero AND 
points revealed by changing closest adaptive area = zero AND 
points revealed by changing next closest adaptive area = zero 
Then suspected points are not partially hidden by a blank [high conf] 

rule 175 

If points revealed by moving solar blank > zero OR 
points revealed by moving 'unar blank > zero OR 
points revealed by changing closest adaptive area > zero OR 
points revealed by changing next closest adaptive area > zero 
Then suspected points are partially hidden by a blank [medium conf] 


level 3 

rule 380 

If there is an expectation of an event [high conf] 
Then the event is expected [high conf] 
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If an event is specifically expected, the system gives more 
credibility to the events. Nonetheless, to ensure that all possible 
events are found, we take a conservative view that there is at least 
medium expectation of an event. 

rule 110 

If distance to coast > map accuracy threshold AND 
the event is not dose to the horizon [high conf] 

Then landsea decision is ok [high conf] 

The accuracy of the DMA 13,000 point world map is about 30 km. 

rule 111 

If distance to ooast <- map accuracy threshold OR 
the event is close to the horizon [high conf] 

Then landsea decision is ok [medium conf] 

The accuracy of the DMA 13,000 point world map is about 30 km. 

rule 374 

If the event is not near the terminator [high conf] 

Then the event is not near local sunrise [high conf] 

To determine if it is local sunrise, we see if there is more daylight 
20 minutes later, and if it is close to the terminator. 

rule 348 

If distance to terminator in 20 minutes < distance to terminator AND 
the event is near the terminator [high conf] 

Then the event is near local sunrise [high conf] 

To determine if it is beat sunrise, we see if there is more daylight 
20 minutes later, and if it is close to the terminator. 

rule 349 

If distance to terminator in 20 minutes < distance to terminator AND 
the event is near the terminator [medium conf] 

Then the event is near local sunrise [medium conf] 

To determine if it is local sunrise, we see if there is more daylight 
20 minutes later, and if it is close to the terminator. 

rule 391 

If distance to terminator in 20 minutes >« distance to terminator 
Then the event is not near local sunrise [high conf] 

To determine if it is local sunrise, we see if there is more daylight 
20 minutes later, and if it is close to the terminator. 

rule 392 

If distance to terminator > zero 

Then the event is in local daylight [high conf] 

The event is computed to be in daylight by knowledge of the sun 
ephemeris and time of day. 









If distance to terminator <- zero AND 
the event is near the terminator [high conf] 

Then the event is in local daylight [high conf] 

Clouds or mountains 4 miles high could be sunlit even if 160 miles 
from the terminator. 

rule 394 

If distance to terminator <« zero AND 
the event is near the terminator [medium conf] 

Then the event is in local daylight [medium conf] 

An object or cloud has to be at least 15 or 20 miles above the earth 
to be sunlit. 

rule 395 

If distance to terminator <« zero AND 
the event is not near the terminator [high conf] 

Then the event is not in local daylight [high conf] 

High clouds (30,000 - 50,000 ft) could be sunlit either directly or 
with atmospheric refraction at this distance from the terminator. 

rule 386 

If the event is over the land [high conf] 

Then the event is not over the sea [high conf] 

rule 340 

If the event is not close to the horizon [high conf] 

Then the moon is not near the event [high conf] 

Only events near the horizon should be affected by this rule. For a 
star or planet, you should wait a few scans and check the motion. 

rule 341 

If the event is over the land [high conf] AND 
landsea decision is ok [high conf] 

Then the event is not wet [high conf] 

rule 342 

If the event is over the sea [high conf] AND 
landsea decision is ok [high conf] 

Then the event is wet [high conf] 

rule 343 

If landsea decision is ok [medium conf] 

Then the event is wet [medium conf] 

The computer is liable to make a region determination error in this case. 

rule 405 

If the scattering angle is not unfavorable [high conf] 

Then the solar scatter is not a clutter source [high conf] 

The scattering angle calculation does not account for whether it is 
local daylight. 







rule 410 

If the reflection geometry is not unfavorable [high conf] 

Then the specular point is not near the event [high conf] 

The reflection calculation does not account for local daylight. 

rule 411 

If event is free of stationary sources [high conf] AND 
event is free of transient noise bursts [high conf] 

Then there are enough clean points in the event [high conf] 

rule 412 

If event is not free of stationary sources [high conf] OR 
event is not free of transient noise bursts [high conf] 

Then there are not enough clean points in the event [high conf] 

rule 413 

If event is free of stationary sources [high conf] AND 
event is free of transient noise bursts [medium conf] 

Then there are enough clean points in the event [medium conf] 

rule 414 

If event is free of stationary sources [medium conf] AND 
event is free of transient noise bursts [medium conf] 

Then there are enough clean points in the event [medium conf] 

rule 415 

If event is free of stationary sources [medium conf] AND 
event is free of transient noise bursts [high conf] 

Then there are enough clean points in the event [medium conf] 

rule 416 

If the event is not overshoot data [high conf] 

Then a concurrent event is not the cause [high conf] 

rule 417 

If the event is overshoot data [high conf] 

Then a concurrent event is the cause [high conf] 

rule 418 

If the event is overshoot data [medium conf] 

Then a concurrent event is the cause [medium conf] 

rule 419 

If the data is due to persistence [high conf] 

Then an earlier event is the cause [high conf] 

rule 420 ' 

It the data is not due to persistence [high coni] 

Then an earlier event is not the cause [high conf] 

rule 421 ; 

If the data is due to persistence [medium conf] 

Then an earlier event is the cause [medium conf] 

rule 367 

If the event is close to the horizon [medium conf] 






Then the event is not caused by a star (or celestial body) [high conf] 

Stars are always above the horizon (as long as the attitude is good). 
rule 368 

If the event is not close to the horizon [high conf] 

Then the event is not caused by a star (or celestial body) [high conf] 

Stars are always above the horizon (as long as the attitude is good). 

rule 371 

If the event intensity is not less than 200 [high conf] 

Then specular reflections is not the cause [high conf] 

Specular reflections from the sea are not bright under normal 
atmospheric conditions. 

rule 149 

If some IR background is normally in this area [high conf] 

Then background sources are historically in this area [high conf] 

rule 150 

If some IR background is not normally in this area [high conf] AND 
the event is not close to the horizon [high conf] 

Then background sources are not historically in this area [high conf] 

rule 151 

If some IR background is not normally in this area [high conf] AND 
the event is close to the horizon [high conf] 

Then background sources are historically in this area [medium conf] 

rule 161 

If distance to the solar blank < close blank distance AND 
distance to the solar blank > very close blank distance AND 
the solar blank is stationary for the event duration [high conf] 

Then there is a static close solar blank [medium conf] 

rule 162 

If distance to the lunar blank < close blank distance AND 
distance to the lunar blank > very close blank distance AND 
the lunar blank is stationary for the event duration [high conf] 

Then there is a static close lunar blank [medium conf] 

rule 163 

H distance to the closest high threshold adaptive area < dose blank distance AND 
distance to the closest high threshold adaptive area > very close blank distance AND 
the closest high threshold adaptive area is stationary [high conf] 

Then there is a static closest adaptive area [medium conf] 

rule 164 

If distance to next closest high threshold adaptive area < close blank distance AND 
distance to next closest high threshold adaptive area > very close blank distance AND 
the next closest high threshold adaptive area is stationary [high conf] 

Then there is a static next closest adaptive area [medium conf] 

rule 165 

If distance to the solar blank < very close blank distance AND 








the solar blank is stationary for the event duration [high conf] 

Then there is a static close solar blank [high conf] 

rule 166 

If distance to the lunar blank < very close blank distance AND 
the lunar blank is stationary for the event duration [high conf] 

Then there is a static close lunar blank [high conf] 

rule 167 

If distance to the closest high threshold adaptive area < very close blank distance AND 
the closest high threshold adaptive area is stationary [high conf] 

Then there is a static closest adaptive area [high conf] 

rule 168 

If distance to next closest high threshold adaptive area < very close blank distance AND 
the closest high threshold adaptive area is stationary [high conf] 

Then there is a static next closest adaptive area [high conf] 

rule 169 

If distance to the solar blank > close blank distance OR 
the solar blank is not stationary for the event duration [high oonf] 

Then there is not a static close solar blank [high conf] 

rule 170 

If distance to the lunar blank > close blank distance OR 
the lunar blank is not stationary for the event duration [high conf] 

Then there is not a static close lunar blank [high conf] 

rule 171 

If distance to the closest high threshold adaptive area > close blank distance OR 
the closest high threshold adaptive area is not stationary [high conf] 

Then there is not a static closest adaptive area [high conf] 

rule 172 

If distance to next closest high threshold adaptive area > close blank distance OR 
the next closest high threshold adaptive area is not stationary [high conf] 

Then there is not a static next closest adaptive area [high conf] 


level 4 
rule 352 

If the event is caused by a star (or celestial body) [high conf] 

Then a known phenomenology source is near the event [high conf] 

Only events near the horizon should be affected by this rule. For a 
star or planet, you should wait a few scans and check the motion. 

rule 382 

If background sources are historically in this area [high conf] 

Then a known phenomenology source is near the event [high conf] 

rule 383 

If background sources are historically in this area [medium conf] 

Then a known phenomenology source is near the event [medium conf] 












If the neighboring data is a "known" non-natural background [high conf] 
Then a known phenomenology source is near the event [high conf] 

rule 385 

If the neighboring data is a "known" non-natural background [medium conf] 
Then a known phenomenology source is near the event [medium conf] 

rule 363 

If the event is near local sunrise [high conf] 

Then a known phenomenology source is near the event [medium conf] 

Local sunrise lights up the background in a few minutes time. This 
temporal variation sometimes causes false events. 

rule 347 

If the event is near local sunrise [medium conf] 

Then a known phenomenology source is near the event [medium conf] 

Local sunrise lights up the background in a few minutes time. This 
temporal variation sometimes causes false events. 

rule 362 

If the sun is in the telescope’s field-of-view [high conf] 

Then a known phenomenology source is near the event [high conf] 

Possible internal optical reflections. 

rule 366 

If the sun is in the telescope’s field-of-view [medium conf] 

Then a known phenomenology source is near the event [medium conf] 

Possible internal optical reflections. 

rule 376 

If the event is wet [high conf] 

Then the event is not in a mountainous area [high conf] 

High mountains and solar reflections off snow and ice cause background 
returns. Mountainous regions are defined by a 102 point data base. 

rule 346 

If the event is not in local daylight [high conf] 

Then the solar scatter is not a clutter source [high conf] 

This background can only occur from reflected sunlight. 

rule 401 

If the scattering angle is unfavorable [high conf] AND 
the event is in local daylight [high conf] 

Then the solar scatter is a clutter source [high conf] 

The scattering angle calculation does not account for whether it is 
local daylight. 

rule 402 

If fhe scattering angle is unfavorable [high conf] AND 
the event is in local daylight [medium conf] 
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Then the solar scatter is a clutter source [high conf] 


The scattering angle calculation does not account for whether it is 
local daylight. 

rule 403 

If the scattering angle is unfavorable [medium conf] AND 
the event is in local daylight [high conf] 

Then the solar scatter is a clutter source [medium conf] 

The scattering angle calculation does not account for whether it is 
local daylight. 

rule 404 

If the scattering angle is unfavorable [medium conf] AND 
the event is in local daylight [medium conf] 

Then the solar scatter is a clutter source [medium conf] 

The scattering angle calculation does not account for whether it is 
local daylight. 


rule 350 

If the moon is near the event [high conf] 

Then a known phenomenology source is near the event [medium conf] 

The Moon or the lunar blank actually go slightly below the horizon 
because the moon is bright. 


rule 351 

If an earlier event is the cause [high conf] AND 
the solar scatter is a clutter source [high conf] 

Then a known phenomenology source is near the event [high conf] 

Persistence. 

rule 353 

If an earlier event is the cause [high conf] AND 
the solar scatter is a clutter source [medium conf] 

Then a known phenomenology source is near the event [medium conf] 

Persistence. 

rule 423 

If an earlier event is the cause [medium conf] AND 
the solar scatter is a clutter source [medium conf] 

Then a known phenomenology source is near the event [medium conf] 

Persistence. 

rule 424 

If an earlier event is the cause [medium conf] AND 
the solar scatter is a clutter source [high conf] 

Then a known phenomenology source is near the event [medium conf] 

Persistence. 

rule 354 
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If a concurrent event is the cause [high conf] 

Then a known phenomenology source is near the event [high conf] 

Overshoot logic. 

rule 422 

If a concurrent event is the cause [medium conf] 

Then a known phenomenology source is near the event [medium conf] 

Overshoot logic. 

rule 377 

If the event is not in local daylight [high conf] 

Then the specular point is not near the event [high conf] 

Reflections from the sea must be close to the specular point to be 
bright, since the specular point is localized. This rule does not take into 
account that specular reflections from mountains could be quite far from 
the specular point. 

rule 406 

If the reflection geometry is unfavorable [high conf] AND 
the event is in local daylight [high conf] 

Then the specular point is near the event [high conf] 

The reflection calculation does not account for local daylight. 

rule 407 

If the reflection geometry is unfavorable [high conf] AND 
the event is in local daylight [medium conf] 

Then the specular point is near the event [high conf] 

The reflection calculation does not account for local daylight. 

rule 408 

If the reflection geometry is unfavorable [medium conf] AND 
the event is in local daylight [high conf] 

Then the specular point is near the event [medium conf] 

The reflection calculation does not account for local daylight. 

rule 409 

If the reflection geometry is unfavorable [medium conf] AND 
the event is in local daylight [medium conf] 

Then the specular point is not near the event [high conf] 

The reflection calculation does not account for local daylight. 

rule 355 

If the event is in a mountainous area [high conf] AND 
the event is in local daylight [high conf] 

Then a known phenomenology source is near the event [high conf] 

High mountains and solar reflections off snow and ice cause background 
returns. Mountainous regions are defined by a 102 point data base. 

rule 425 


32 









If the event is in a mountainous area [high conf] AND 
the event is in local daylight [medium conf] 

Then a known phenomenology source is near the event [medium conf] 

High mountains and solar reflections off snow and ice cause background 
returns. Mountainous regions are defined by a 102 point data base. 

rule 426 

If the event is in a mountainous area [medium conf] AND 
the event is in local daylight [medium conf] 

Then a known phenomenology source is near the event [medium conf] 

High mountains and solar reflections off snow and ice cause background 
returns. Mountainous regions are defined by a 102 point data base. 

rule 356 

If the solar scatter is a clutter source [high conf] 

Then a known phenomenology source is near the event [medium conf] 

Low angle scatter will only be a problem if there are high clouds. In 
general, we don't know the weather that well. 

rule 357 

If the solar scatter is a clutter source [medium conf] 

Then a known phenomenology source is near the event [medium conf] 

Low angle scatter will only be a problem if there are high clouds. In 
general, we don't know the weather that well. 

rule 358 

If the specular point is near the event [high conf] AND 
the event intensity is less than 200 [high conf] 

Then specular reflections is the cause [high conf] 

Specular reflections from the sea are not bright under normal 
atmospheric conditions. 

rule 369 

If the specular point is not near the event [high conf] 

Then specular reflections is not the cause [high conf] 

Reflections from the sea must be dose to the specular point to be 
bright, since the specular point is localized. This rule does not take into 
account that specular reflections from mountains could be quite far from 
the specular point. 

rule 370 

If the specular point is near the event [medium conf] 

Then specular reflections is not the cause [high conf] 

Reflections from the sea must be dose to the specular point to be 
bright, since the specular point is localized. This rule does not take into 
account that specular refactions from mountains could be quite far from 
the specular point. 

rule 359 

If specular reflections is the cause [high conf] AND 












the event is wet [high conf] 

Then a known phenomenology source is near the event [high conf] 

Rules 359-361 say that if the event is wet and specular reflections 
were present, then we know the background. Otherwise, we might know the 
background which could be a lake or river, for example. 

rule 360 

If specular reflections is the cause [high conf] AND 
the event is wet [medium conf] 

Then a known phenomenology source is near the event [medium conf] 

Rules 359-361 say that if the event is wet and specular reflections 
were present, then we know the background. Otherwise, we might know the 
background which could be a lake or river, for example. 

rule 361 

If specular reflections is the cause [high conf] AND 
the event is not wet [high conf] 

Then a known phenomenology source is near the event [medium conf] 

Rules 359-361 say that if the event is wet and specular reflections 
were present, then we know the background. Otherwise, we might know the 
background which could be a lake or river, for example. 

rule 364 

If the event is in a mountainous area [medium conf] AND 
the event is in local daylight [high conf] 

Then a known phenomenology source is near the event [medium conf] 

High mountains and solar reflections off snow and ice cause background 
returns. Mountainous regions are defined by a 102 point data base. 

rule 365 

If the event is not in a mountainous area [high conf] AND 
the event is in local daylight Ihigh conf] 

Then a known phenomenology source is near the event [medium conf] 

High mountains and solar reflections off snow and ice cause background 
returns. Mountainous regions are defined by a 102 point data base. 

rule 372 

If the event is not in local daylight [high conf] 

Then the specular point was not the cause [high conf] 

This background can only occur from reflected sunlight. 

rule 373 

If the event is not in local daylight [high conf] 

Then mountains are not the cause [high conf] 

This background can only occur from reflected sunlight. 

rule 378 

If the event is not in a mountainous area [high conf] 

Then mountains are not the cause [high conf] 
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This background can only occur from reflected sunlight. 

rule 375 

If a concurrent event is not the cause [high conf] AND 
an earlier event is not the cause [high conf] 

Then other events are not the cause [high conf] 

No overshoots or new phenomenobgy. 

rule 177 

H there is not a static close solar blank [high conf] AND 
there is not a static close lunar blank [high conf] AND 
there is not a static closest adaptive area [high conf] AND 
there is not a static next closest adaptive area [high conf] 
Then there is not at least one close static blank [high conf] 
Else there is at least one close static blank [high conf] 

rule 178 

If there is a static close solar blank [medium conf] AND 
there is a static close lunar blank [medium conf] 

Then there is more than one close static blank [high conf] 

rule 179 

If there is a static close solar blank [medium conf] AND 
there is a static closest adaptive area [medium conf] 

Then there is more than one close static blank [high conf] 

rule 180 

if there is a static close solar blank [medium conf] AND 
there is a static next closest adaptive area [medium conf] 
Then there is more than one close static blank [high conf] 

rule 181 

If there is a static close lunar blank [medium conf] AND 
there is a static closest adaptive area [medium conf] 

Then there is more than one close static blank [high conf] 

rule 182 

If there is a static close lunar blank [medium conf] AND 
there is a static next closest adaptive area [medium conf] 
Then there is more than one close static blank [high conf] 

rule 183 

If there is a static closest adaptive area [medium conf] AND 
there is a static next closest adaptive area [medium conf] 
Then there is more than one close static blank [high conf] 

rule 184 

If there is not a static close solar blank [high conf] AND 
there is not a static close lunar blank [high conf] AND 
there is not a static closest adaptive area [high conf] 

Then there is not more than one close static blank [high conf] 

rule 185 

If there is not a static close solar blank [high conf] AND 
there is not a static close lunar blank [high conf] AND 
there is not a static next closest adaptive area [high conf] 
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Then there is not more than one close static blank [high conf] 
rule 186 

It there is not a static close solar blank [high conf] AND 
there is not a static closest adaptive area [high conf] AND 
there is not a static next closest adaptive area [high conf] 
Then there is not more than one close static blank [high conf] 

rule 187 

If there is not a static close lunar blank [high conf] AND 
there is not a static closest adaptive area [high conf] AND 
there is not a static next closest adaptive area [high conf] 
Then there is not more than one close static blank [high conf] 

rule 176 

If there is a static close solar blank [high conf] OR 
there is a static close lunar blank [high conf] OR 
there is a static closest adaptive area [high conf] OR 
there is a static next closest adaptive area [high conf] 

Then some static blank is very close [high conf] 

Else some static blank is not very close [high conf] 


level 5 
rule 153 

H the event is near Arctic ice [high conf] AND 
the specular point is near the event [high conf] 

Then a known phenomenology source is near the event [high conf] 

rule 154 

If the event is near Arctic ice [high conf] AND 
the specular point is near the event [medium conf] 

Then a known phenomenology source is near the event [medium conf] 

rule 155 

If the event is near Arctic ice [high conf] AND 
the specular point is not near the event [high conf] 

Then the Arctic ice is not a problem [high conf] 

rule 156 

If the event is not near Arctic ice [high conf] 

Then the Arctic ice is not a problem [high conf] 

Else the Arctic ice is a problem [high conf] 

rule 188 

If there is not more than one close static blank [high conf] AND 
there is at least one close static blank [high conf] 

Then there is exactly one close static blank [high conf] 

Else there is not exactly one close static blank [high conf] 

rule 189 

If some static blank is very close [high conf] AND 
number of non-event points in proximity >* one 
Then a leaking static blank is likely [high conf] 

rule 190 
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If there is more than one close static blank [high conf] AND 
number of non-event points in proximity » one 
Then a leaking static blank is likely [high conf] 

rule 191 

If there is not at least one close static blank [high conf] 

Then a leaking static blank is not likely [high conf] 

rule 192 

If some static blank is very close [high conf] AND 
number ot non-event points in proximity = zero AND 
suspected points are partially hidden by a blank [high conf] 
Then a leaking static blank is likely [high conf] 

rule 193 

If some static blank is very close [high conf] AND 
number of non-event points in proximity - zero AND 
suspected points are partially hidden by a blank [medium conf] 
Then a leaking static blank is likely [high conf] 

rule 194 

If some static blank is very close [high conf] AND 
number of non-event points in proximity » zero AND 
suspected points are not partially hidden by a blank [high conf] 
Then a leaking static blank is likely [medium conf] 

rule 195 

If there is more than one close static blank [high conf] AND 
number of non-event points in proximity - zero AND 
suspected points are partially hidden by a blank Ihigh conf] 
Then a leaking static blank is likely [high conf] 

rule 196 

If there is more than one close static blank [high conf] AND 
number of non-event points in proximity - zero AND 
suspected points are partially hidden by a blank [medium conf] 
Then a leaking static blank is likely [high conf] 

rule 197 

If there is more than one close static blank [high conf] AND 
number of non-event points in proximity - zero AND 
suspected points are not partially hidden by a blank [high conf] 
Then a leaking static blank is likely [medium conf] 


level 6 

rule 437 

If the event is not near local sunrise [high conf] AND 
the moon is not near the event [high conf] AND 
the solar scatter is not a clutter source [high conf] AND 
specular reflections is not the cause [high conf] AND 
background sources are not historically in this area [high conf] AND 
the neighboring data is not a ’known’ non-natural background [hirh conf] AND 
the sun is not in the telescope s field-of-view [high conf] AND 
other events are not the cause [high conf] AND 
mountains are not the cause [high conf] AND 
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the Arctic ice is not a problem [high conf] AND 
the event is not caused by a star (or celestial body) [high conf] 

Then a known phenomenology source is not near the event [high conf] 

rule 198 

If there is exactly one close static blank [high conf] AND 
some static blank is not very close [high conf] AND 
suspected points are partially hidden by a blank [high conf] 

Then a leaking static blank is likely [high conf] 

rule 199 

If there is exactly one close static blank [high conf] AND 
some static blank is not very close [high conf] AND 
suspected points are partially hidden by a blank [medium conf] AND 
number of non-event points in proximity = one 
Then a leaking static blank is likely [high conf] 

rule 200 

If there is exactly one close static blank [high conf] AND 
some static blank is not very close [high conf] AND 
suspected points are partially hidden by a blank [medium conf] AND 
number of non-event points in proximity * zero 
Then a leaking static blank is likely [medium conf] 

rule 201 

If there is exactly one close static blank [high conf] AND 
some static blank is not very close [high conf] AND 
suspected points are not partially hidden by a blank [high conf] AND 
number of non-event points in proximity - one 
Then a leaking static blank is likely [medium conf] 

rule 202 

If there is exactly one close static blank [high conf] AND 
some static blank is not very close [high conf] AND 
suspected points are not partially hidden by a blank [high conf] AND 
number of non-event points in proximity = zero 
Then a leaking static blank is not likely [high conf] 


level 7 
rule 203 

If a leaking static blank is not likely [high conf] AND 
there is significant random clutter [high conf] 

Then observed data clusters are near the event [high conf] 

rule 204 

If a leaking static blank is not likely [high conf] AND 
there is significant random clutter [medium conf] 

Then observed data clusters are near the event [medium conf] 

rule 205 

If a leaking static blank is not likely [high conf] AND 
there is not significant random clutter [high conf] 

Then observed data clusters are not near the event [high conf] 

rule 206 




38 








If a leaking static blank is likely [high conf] AND 
there is significant random clutter [high conf] 

Then observed data clusters are near the event [high conf] 

rule 207 

If a leaking static blank is likely [high conf] AND 
there is significant random clutter [medium conf] 

Then observed data clusters are near the event [high conf] 

rule 208 

If a leaking static blank is likely [high conf] AND 
there is not significant random clutter [high conf] 

Then observed data clusters are near the event [high conf] 

rule 209 

If a leaking static blank is likely [medium conf] AND 
there is significant random clutter [high conf] 

Then observed data clusters are near the event [high conf] 

rule 210 

If a leaking static blank is likely [medium conf] AND 
there is significant random clutter [medium conf] 

Then observed data clusters are near the event [high conf] 

rule 211 

If a leaking static blank is likely [medium conf] AND 
there is not significant random clutter [high conf] 

Then observed data clusters are near the event [medium conf] 


level 8 

rule 335 

If observed data clusters are near the event [medium conf] AND 
a known phenomenology source is near the event [high conf] 

Then background clutter is present [high conf] 

The collection of rules 330-339 combine the a priori knowledge of 
background with the observed background on the display to estimate the 
confidence that the event is due to background. Should add observed blanks 
to this logic. 

rule 336 

If observed data clusters are near the event [medium conf] AND 
a known phenomenology source is near the event [medium conf] 

Then background clutter is present [medium conf] 

The collection of rules 330-339 combine the a priori knowledge of 
background with the observed background on the display to estimate the 
confidence that the event is due to background. Should add observed blanks 
to this logic. 

rule 337 

If observed data clusters are near the event [medium conf] AND 
a known phenomenology source is not near the event [high conf] 

Then background clutter is present [medium conf] 
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The collection of rules 330-339 combine the a priori knowledge of 
background with the observed background on the display to estimate the 
confidence that the event is due to background. Should add observed blanks 
to this logic. 

rule 338 

If observed data clusters are not near the event [high conf] AND 
a known phenomenology source is near the event [high conf] 

Then background clutter is present [medium conf] 

The collection of rules 330-339 combine the a priori knowledge of 
background with the observed background on the display to estimate the 
confidence that the event is due to background. Should add observed blanks 
to this logic. 

rule 339 

H observed data clusters are not near the event [high conf] AND 
a known phenomenology source is near the event [medium conf] 

Then background clutter is present [medium conf] 

The collection of rules 330-339 combine the a priori knowledge of 
background with the observed background on the display to estimate the 
confidence that the event is due to background. Should add observed blanks 
to this logic. 

rule 334 

If observed data clusters are near the event [high conf] AND 
a known phenomenology source is near the event [medium conf] 

Then background clutter is present [high conf] 

The collection of rules 330-339 combine the a priori knowledge of 
background with the observed background on the display to estimate the 
confidence that the event is due to background. Should add observed blanks 
to this logic. 

rule 332 

If observed data clusters are near the event [high conf] AND 
a known phenomenology source is not near the event [high conf] 

Then background clutter is present [medium conf] 

The collection of rules 330-339 combine the a priori knowledge of 
background with the observed background on the display to estimate the 
confidence that the event is due to background. Should add observed blanks 
to this logic. 

rule 331 

If observed data clusters are near the event [high conf] AND 
a known phenomenology source is near the event [high conf] 

Then background clutter is present [high conf] 

The collection of rules 330-339 combine the a priori knowledge of 
background with the observed background on the display to estimate the 
confidence that the event is due to background. Should add observed blanks 
to this logic. 

rule 330 

If observed data clusters are not near the event [high conf] AND 
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a known phenomenology source is not near the event [high conf] 
Then background clutter is not present [high conf] 


The collection of rules 330-339 combine the a priori knowledge of 
background with the observed background on the display to estimate the 
confidence that the event is due to background. Should add observed blanks 
to this logic. 


rule 430 

N there are enough clean points in the event [high conf] AND 
background clutter is present [high conf] 

Then the event is due to background [medium conf] 

rule 431 

If there are enough clean points in the event [high conf] AND 
background clutter is present [medium conf] 

Then the event is not due to background [high conf] 

rule 432 

If there are enough clean points in the event [high conf] AND 
background clutter is not present [high conf) 

Then the event is not due to background [high conf] 

rule 433 

If there are enough clean points in the event [medium conf] AND 
background clutter is present [high conf] 

Then the event is due to background [high conf] 

rule 434 

If there are enough clean points in the event [medium conf] AND 
background clutter is present [medium conf] 

Then the event is due to background [medium conf] 

rule 435 

If there are enough clean points in the event [medium conf] AND 
background clutter is not present [high conf] 

Then the event is due to background [medium conf] 

rule 436 

If there are not enough clean points in the event [high conf] 

Then the event is due to background [high conf] 


level 10 

rule 379 

If there is not an expectation of an event [low conf] OR 
there is not an expectation of an event [medium conf] OR 
there is not an expectation of an event [high conf] OR 
there is an expectation of an event [low conf] OR 
there is an expectation of an event [medium conf] 

Then the event is expected [medium conf] 


True-medium is normal alertness level. Tme-high is for tip-offs. 










False-high is for very unexpected things such as wet events in land areas. 


rule 381 

If the system is functioning properly [high conf] 

Then attitude is not the only suspected system error [high conf] 

rule 387 

If the system is functioning property [medium conf] 

Then attitude is the only suspected system error [medium conf] 

rule 388 

If the system is not functioning properly [high conf] 

Then attitude is not the only suspected system error [high conf] 

rule 324 

If the event is due to background [medium conf] AND 
the event is due to noise [medium conf] 

Then the technical evaluation of the event is good [medium conf] 

Rules 320-324 combine the noise and background knowledge into a 
technical evaluation of the event confidence. 

rule 323 

If the event is due to background [high conf] OR 
the event is due to noise [high conf] 

Then the technical evaluation of the event is not good [high conf] 

Rules 320-324 combine the noise and background knowledge into a 
technical evaluation of the event confidence. 

rule 322 

If the event is due to background [medium conf] AND 
the event is not due to noise [high conf] 

Then the technical evaluation of the event is good [medium conf] 

Rules 320-324 combine the noise and background knowledge into a 
technical evaluation of the event confidence. 

rule 321 

If the event is not due to background [high conf] AND 
the event is due to noise [medium conf] 

Then the technical evaluation of the event is good [medium conf] 

Rules 320-324 combine the noise and background knowledge into a 
technical evaluation of the event confidence. 

rule 320 

If the event is not due to background [high conf] AND 
the event is not due to noise [high conf] 

Then the technical evaluation of the event is good [high conf] 

Rules 320-324 combine the noise and background knowledge into a 
technical evaluation of the event confidence. 













level 11 


rule 315 

If the system is not functioning properly [high conf] AND 
attitude is the only suspected system error [medium conf] AND 
the event is expected [high conf] AND 
the technical evaluation of the event is not good [high conf] 

Then the event is not valid [high conf] 

If the system is not functioning properly, we try to find out if 
only the attitude is bad. If this is the case, and the intensity profile is 
OK, the event is probably OK even if its motion is poor. If there are other 
problems, we lower our confidence in the event. 

rule 314 

If the system is not functioning properly [high conf] AND 
attitude is the only suspected system error [medium conf] AND 
the event is expected [medium conf] AND 
the technical evaluation of the event is not good [high conf] 

Then the event is not valid [high conf] 

If the system is not functioning properly, we try to find out if 
only the attitude is bad. If this is the case, and the intensity profile is 
OK, the event is probably OK even if its motion is poor. If there are other 
problems, we lower our conf idence in the event. 

rule 313 

If the system is not functioning properly [high conf] AND 
attitude is the only suspected system error [medium conf] AND 
the event is expected [medium conf] AND 
the technical evaluation of the event is good [medium conf] 

Then the event is not valid [high conf] 

If the system is not functioning properly, we try to find out if 
only the attitude is bad. If this is the case, and the intensity profile is 
OK, the event is probably OK even if its motion is poor. If there are other 
problems, we lower our confidence in the event. 

rule 312 

If the system is not functioning properly [high conf] AND 
attitude is the only suspected system error [medium conf] AND 
the event is expected [medium conf] AND 
the technical evaluation of the event is good [high conf] 

Then the event is valid [medium conf] 

If the system is not functioning properly, we try to find out if 
only the attitude is bad. If this is the case, and the intensity profile is 
OK, the event is probably OK even if its motion is poor. If there are other 
problems, we lower our confidence in the event. 

rule 311 

If the system is not functioning properly [high conf] AND 
attitude is the only suspected system error [medium conf] AND 
the event is expected [high conf] AND 
the technical evaluation of the event is good [high conf] 

Then the event is valid [medium conf] 
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If the system is not functioning property, we try to find out if 
only the attitude is bad. If this is the case, and the intensity profile is 
OK, the event is probably OK even if its motion is poor. If there are other 
problems, we lower our confidence in the event. 

rule 310 

If the system is not functioning properly [high conf] AND 
attitude is the only suspected system error [medium conf] AND 
the event is expected [high conf] AND 
the technical evaluation of the event is good [medium conf] 

Then the event is valid [medium conf] 

If the system is not functioning properly, we try to find out if 
only the attitude is bad. If this is the case, and the intensity profile is 
OK, the event is probably OK even if its motion is poor. If there are other 
problems, we lower our confidence in the event. 

rule 309 

If the system is not functioning properly [high conf] AND 
attitude is the only suspected system error [high conf] AND 
the intensity profile is not reasonable [high conf] 

Then the event is not valid [high conf] 

If the system is not functioning properly, we try to find out if 
only the attitude is bad. If this is the case, and the intensity profile is 
OK, the event is probably OK even if its motion is poor. If there are other 
problems, we lower our confidence in the event. 

rule 308 

If the system is not functioning properly [high conf] AND 
attitude is the only suspected system error [high conf] AND 
the intensity profile is reasonable [high conf] AND 
the event is expected [medium conf] 

Then the event is valid [high conf] 

If the system is not functioning properly, we try to find out if 
only the attitude is bad. If this is the case, and the intensity profile is 
OK, the event is probably OK even if its motion is poor. If there are other 
problems, we lower our confidence in the event. 

rule 307 

If the system is not functioning properly [high conf] AND 
attitude is the only suspected system error [high conf] AND 
the intensity profile is reasonable [high conf] AND 
the event is expected [high conf] 

Then the event is valid [high conf] 

If the system is not functioning properly, we try to find out if 
only the attitude is bad. If this is the case, and the intensity profile is 
OK, the event is probably OK even if its motion is poor. If there are other 
problems, we lower our confidence in the event. 

rule 306 

H the system is functioning properly [high conf] AND 
the technical evaluation of the event is not good [high conf] AND 
the event is expected [high conf] 

Then the event is valid [medium conf] 







This is a judgement rule based on expectation and technical evaluation. 


rule 305 

It the system is functioning properly [high conf] AND 
the technical evaluation of the event is not good [high conf] AND 
the event is expected [medium conf] 

Then the event is not valid [high conf] 

This is a judgement mle based on expectation and technical evaluation. 

rule 304 

If the system is functioning properly [high conf] AND 
the technical evaluation of the event is good [medium conf] AND 
the event is expected [medium conf] 

Then the event is valid [medium conf] 

This is a judgement mle based on expectation and technical evaluation. 

mle 301 

If the system is functioning properly [high conf] AND 
the event is expected [medium conf] AND 
the technical evaluation of the event is good [high conf] 

Then the event is valid [high conf] 

This is a judgement mle based on expectation and technical evaluation. 
mle 302 

If the system is functioning properly [high conf] AND 
the event is expected [high conf] AND 
the technical evaluation of the event is good [medium conf] 

Then the event is valid [high conf] 

This is a judgement mle based on expectation and technical evaluation. 
mle 303 

If the system is functioning properly [high conf] AND 
the event is expected [high conf] AND 
the technical evaluation of the event is good [high conf] 

Then the event is valid [high conf] 

This is a judgement mle based on expectation and technical evaluation. 

mle 317 ! 

If the event is not expected [high conf] AND ] 

the system is not functioning properly [high conf] , 

Then the event is not valid [high conf] .j 

If the system is not functioning properly, we try to find out if ( 

only the attitude is bad. If this is the case, and the intensity profile is 
OK, the event is probably OK even H its motion is poor. If there are other 
problems, we tower our confidence in the event. 

mle 316 

If the event is not expected [high conf] AND | 

the technical evaluation of the event is good [high conf] AND 
the system is functioning property [high conf] 

Then the event is valid [medium conf] 
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Very unexpected events are rejected unless everything else looks great. 


rule 318 

If the event is not expected (nigh conf] AND 
the technical evaluation of the event is good [high conf] AND 
the system is functioning properly [medium conf] 

Then the event is valid [medium conf] 

If the system is not functioning properly, we try to find out if 
only the attitude is bad. If this is the case, and the intensity profile is 
OK, the event is probably OK even if its motion is poor. If there are other 
problems, we lower our confidence in the event. 

rule 319 

If the event is not expected [high conf] AND 
the technical evaluation of the event is good [medium conf] AND 
the system is functioning properly [medium conf] 

Then the event is not valid [high conf] 

If the system is not functioning properly, we try to find out if 
only the attitude is bad. If this is the case, and the intensity profile is 
OK, the event is probably OK even if its motion is poor. If there are other 
problems, we lower our confidence in the event. 

rule 325 

If the event is not expected [high conf] AND 
the technical evaluation of the event is not good [high conf] AND 
the system is functioning properly [medium conf] 

Then the event is not valid [high conf] 

If the system is not functioning properly, we try to find out if 
only the attitude is bad. If this is the case, and the intensity profile is 
OK, the event is probably OK even if its motion is poor. If there are other 
problems, we lower our confidence in the event. 

rule 326 

If the event is not expected [high conf] AND 
the technical evaluation of the event is good [medium conf] AND 
the system is functioning properly [high conf] 

Then the event is not valid [high conf] 

If the system is not functioning properly, we try to find out if 
only the attitude is bad. If this is the case, and the intensity profile is 
OK, the event is probably OK even if its motion is poor. If there are other 
problems, we lower our confidence in the event. 

rule 327 

H the event is not expected [high conf] AND 
the technical evaluation of the event is not good [high conf] AND 
the system is functioning properly [high conf] 

Then the event is not valid [high conf] 

If the system is not functioning properly, we try to find out if 
only the attitude is bad. If this is the case, and the intensity profile is 
OK, the event is probably OK even if its motion is poor. If there are other 
problems, we lower our confidence in the event. 








4. IMPLEMENTATION DETAILS 


4.1. TABLES 

The expert system is largely table-driven, which is a software engineering feature used for clarity both 
in the expert system's organization as well as within the software. Here is a brief overview of what the 
tables are and where they come into play. A list of them follows: 

Rules 

Assertions 

Limits 

Remarks 

Diagnostics 

Implicit 

4.1.1. Rules 

The rule table is also known as the knowledge base. This is the repository for the human expert’s 
knowledge about the domain, which in this case is how to determine whether data taken by a satellite 
'matches' a paticular pattern. This we have termed static knowledge, in that the rules themselves do not 
change while the expert system is making an analysis. 

4.1.2. Assertions 

The assertion table contains dynamic knowledge. It has the assertions about the event, the satellite, or 
any relevent information. These are specific for each case being studied. During the execution of the 
expert system they will take on values, which will be either numeric, 

•g. distance to the terminator ■ 100 km., 
or the values will be a truth value with a certain confidence level, 

eg. The technical evaluation of the event is good [high conf]. 

4.1.3. Limits 

The limits table has thresholds for use with the rule base. Rules may make numeric comparisons of the 
form: 

If assertion-value comparison-operator threshold 
Then assertion, 
as in the following example: 

If specular point < min specular refl angle 
Then the reflection geometry is unfavorable. 
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4.1.4. Remarks 


The remark table has oomments about the rules and assertions. These remarks expand upon and 
explain the relevence of the information in the knowledge base and rule table. When the system queries 
the user for information, the user has the option to request an explanation about why the question was 
asked or for an amplification of what the assertion means. Although the remarks are stored in a separate 
table, they have been printed out in conjunction with the appropriate rules and assertions . 

4.1.5. Diagnostics 

The diagnostics table keeps track of physical information about the event, such as the event’s location 
or how many points comprise the event. The table also has diagnostics about the state of the satellite¬ 
sensor-onboard processing system. If a blank was leaking, a message to that effect would be written 
here. The aim of the diagnostics table is to provide the user quick access to information determining the 
health of the system which has collected, measured and analyzed the event. 

4.1.6. Implicit 

The implicit table is used by the implicit controller program to connect the data reduction procedures, 
called the implicit routines, with the main expert system. The controller, called from the main system, 
starts execution of the implicit routines named in the table. The results are then stored in the assertion 
table for use by the inferencing mechanism in evaluating the rules on successive levels of the knowledge 
base. The implicit level is the first or lowest level. 

The expert system begins with initialization. The user is asked to select the date of the event to be 
validated. Then the knowledge for which the system is called an expert is read. This involves reading 
rules from the rule table or knowledge base, values and assertions from the assertion table, thresholds 
from the limits table, and comments about the rules or assertions from the remarks table. Figure 3 shows 
the initialization process. Once the tables have been read, a diagnostics table is created and then the 
implicit level controller is invoked. 
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Figure 3. Initialization 
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4.2. IMPLICIT LEVEL OPERATION 


Figure 4 shows how the implicit level fits into the expert system. The bold arrows show the main flow 
of command. The parts of the system represented by ellipses are to signify the course through the expert 
system, and are not part of the implicit level operation. 

The implicit controller reads the implicit table which names the implicit routines to be run. Using a table 
achieves independence of these data reduction routines from the main inferencing system, facilitating the 
addition of new routines. 

The controller starts execution of the data reduction routines reading the delog data and the world data 
bases to determine the environment which surrounds the event and the state of the sensors and on-board 
processing. The results are fed back to the controller which then stores the values in the assertion table. 
These assertions become the input features to the expert system. At the same time, any diagnostics 
reported by the routines are written to the diagnostics table. This latter table is an alarm log, pinpointing 
any key features the system has found. It is also used as a scratch pad to keep track of what has been 
determined about the event, such as the number of points and its location. 

When all of the implicit routines have been executed, the implicit controller relinquishes control and the 
inference engine starts its course. 





























4.3. ASSERTIONS 


The following is a list of assertions and value names. The latter are mainly the results from the implicit 
calculations. Thus, "distance to horizon" might have a value of 100 km, whereas "the event is expected" 
would have a truth value and confidence level, "true with high confidence". 

1. distance to horizon 

2. probability that the event is caused by noise 

3. the event origin 

4. The event is over the land. 

5. the event intensity 

6. the origin of the event 

7. the intensity pattern 

8. The event is over the sea. 

9. distance to terminator 

10. distance to terminator in 20 minutes 

11. the region is mountainous 

12. angular distance to sun 

13. scattering angle 

14. specular point 

15. local number of events 

Within the same or a neighboring sector, within 2 minutes 

16. number of points passing stationary source test 

The stationary source tests look for two other points at the same location within two minutes. 

17. number of points passing transient noise test 
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Ringers and strobes are included in transient noise. 


18. Event is free of stationary sources. 

19. Event is free of transient noise bursts. 

20. number of non-overshoot points 

21. number of non-persisting returns 

22. number of non-over-the-horizon points 

23. number of non-event points in proximity 

24. The scattering angle is unfavorable. 

25. The reflection geometry is unfavorable. 

26. A leaking static blank is likely. 

27. distance to the solar blank 

Distance is measured to the boundary of the blank. Solar and lunar blank is at PCM 31. A distance of 
10000 means the blank was non-existent. 

28. distance to the lunar blank 

Distance is measured to the boundary of the blank. Solar and lunar blank is at PCM 31. A distance of 
10000 means the blank was non-existent. 

29. distance to the closest high threshold adaptive area 

30. distance to next closest high threshold adaptive area 

31. stationary solar blank 

32. distance to coast 

33. stationary closest adaptive area blank 

34. stationary next closest adaptive area blank 

35. Landsea decision is ok. 
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36. The event is overshoot data. 


37. The data is due to persistence. 

38. stationary lunar blank 

39. The closest high threshold adaptive area is stationary. 

40. The next closest high threshold adaptive area is stationary. 

41. points revealed by moving solar blank 

These points are the number per scan within 50 arcsecs of the event whose threshold is above the 
second brightest event point. 

42. points revealed by moving lunar blank 

These points are the number per scan within 50 arcsecs of the event whose threshold is above the 
second brightest event point. 

43. points revealed by changing closest adaptive area 

These points are the number per scan within 50 arcsecs of the event whose threshold is above the 
second brightest event point. 

44. points revealed by changing next closest adaptive area 

These points are the number per scan within 50 arcsecs of the event whose threshold is above the 
second brightest event point. 

45. the region is Arctic ice 

46. the event is in a historical background region 

47. Some IR background is normally in this area. 

48. The event is near Arctic ice. 

49. The Arctic ice is a problem. 

50. Some static blank is very close. 

51. There is more than one close static blank. 
















52. There is at least one close static blank. 


53. There is exactly one close static blank. 

54. the number of points in the collected event 

55. There is a static close solar blank. 

56. There is a static dose lunar blank. 

57. There is a static dosest adaptive area. 

58. There is a static next closest adaptive area. 

59. Suspected points are partially hidden by a blank. 

60. The system is functioning properly. 

61. The technical evaluation of the event is good. 

62. The event is expected. 

63. There is an expectation of an event. 

64. The solar blank is stationary for the event duration. 

65. The lunar blank is stationary for the event duration. 

66. Attitude is the only suspected system error. 

67. The intensity profile is reasonable. 

68. Background sources are historically in this area. 

69. The neighboring data is a "known" non-natural background. 
Mission B, for example. 

70. There is significant random dutter. 

71. Background clutter is present. 

72. The event is due to background. 

73. The event is due to noise. 
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74. A known phenomenology source is near the event. 

75. Observed data clusters are near the event. 

76. There are enough clean points in the event. 

77. The event is close to the horizon. 

78. The event is caused by a star (or celestial body). 

79. The event is in a mountainous area. 

80. The sun is in the telescope’s field-of-view. 

81. The moon is near the event. 

82. The event is near the terminator. 

83. The event is near local sunrise. 

84. The event is in local daylight. 

85. The sun is near the event. 

86. An earlier event is the cause. 

87. A concurrent event is the cause. 

88. The solar scatter is a clutter source. 

89. The specular point is near the event. 

90. The event is wet. 

91. The specular point was the cause. 

92. Mountains are the cause. 

93. Specular reflections is the cause. 

94. Solar effects are the cause. 

95. Miscellaneous effects are the cause. 









97. The event is valid. 


!. The event intensity is less than 200. 








4.4. THRESHOLDS TABLE 


Some of the rules compare the values of assertions to thresholds or limits. The numerical values of the 


thresholds are stored in the Threshold Table which follows. 


To Be Determined. 
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4.5. GRAMMAR 


The rules are written in a stylized format that is a compromise between being easy for the computer to 
interpret and easy to convert into an English sentence. The stylized format is the grammar of the rule 
base. 

The rules are of two types. Their format may contain a numerical comparison, and hence a comparison 
operator, or they may test the values of assertion(s), possibly connected by "AND" or "OR". The first case 
would appear as: 

IF A comparison-operator B 
THEM C 
[ELSE D] 

where A is a value name, B is either a value name or a threshold and C is the conclusion. Allowable 
comparison operators include >=, <=, =, >, <, I*. "ELSE D" is optional. It is asserted if the antecedent is 
false. An example of this type of rule is: 

IF angular distance to sun > optical off-axis max angle 

THEN the sun is not in the telescope's field-of-view [high conf]. 


The second kind of rule 

IF A [AND 
B AND 
C] 

THEN D 

[ELSE E] 

The rule-interpretation subroutine determines the truth value of the conditions of the given rule, and 
interprets how they are connected (by AND, OR, or by a mathematical comparison operator). In the case 
of comparison, the objects being compared must be retrieved. There are two ways this can happen. If the 
comparison is of one assertion value with another assertion value, the inference engine seeks both 
values in the assertion table, whereas if the comparison is of an assertion value to a threshold, the 
threshold is retrieved from the limit table. 

Once the truth value of each conditional assertion is known, then the truth value of the rule as a whole 
can be evaluated. The conditions are true only if the truth value and confidence level of each assertion is 
exactly met. If any assertion has an unassigned value, the rule will not be fired. 










4.6. DATA FORMATS 


A large variety of data was extracted from the recorded mission data in order to provide the required 
inputs to the expert system. This section lists the formats of the data input tables that were prepared for 
use by the implicit routines. 


4.6.1. raw 


gmt 

1st 

Ion 

azimuth 
elevation 
intansity 
call# 

1.000 

adjacancias 
#call responded 
flag 


seconds 

degrees 

degrees 

radians 

radians 


4.6.2. event 


origin time 
satellite lat 
satellite Ion 
phase time 
delta gmt 
event lat 
event Ion 
intensity 
flag 

event azim 
event elev 


seconds 

degrees 

degrees 

seconds 

seconds 

degrees 

degrees 


radians 

radians 


4.6.3. ephemeris 


record 1 


diet to earth ctr 
satellite subpt lat 
satellite aubpt Ion 
sun azimuth 


radians 

radians 

radians 


record 2 

sun elevation 
specular pt az 
specular pt el 
eca horiz 
eca nadir 


radians 

radians 


radians 

radians 













4.6.4. blanks 


solar & lunar blanks 

gmt 

left azimuth 
right azimuth 
lower elevation 
upper elevation 
solar or lunar flag 

adapative area blanks 

gmt 

size 

threshold 

age 

density 

azimuth 

elevation 

status 

delta azimuth 
delta elevation 
distance to event 


seconds 

radians 

radians 

radians 

radians 

1 (* solar) or 


seconds 


radians 

radians 

arcsec 

arcsec 

arcsec 


-1 (■ lunar) 


4.6.5. rule.base 

rule number 

line# of rule or zero if simple rule 

level 

IF value# 

comparison symbol (<><=>=* !*) 

threshold# starting with the latter "t" or value# 

IF truth of IF value 
IF confidence of IF value 
conjunction (AND or OR) 

THEN value# 

THEN truth of THEN value 
THEN confidence of THEN value 
ELSE value# 

ELSE truth of ELSE value 
ELSE confidence of ELSE value 

rule category (phenomenology, sensor, etc.) - not used 
remark# 


4.6.6. value.tbl 

value# 

value name/assertion 
value 

rule# or program 

truth 

confidence 

level# 

remark# 










4.6.7. thresh.tbl 

limit# 


value 

units 


4.6.8. remark.tbl 

remark# 

comments 


4.6.9. impllcit.tbl 

procedure 

value# 


63 
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END 
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